Hello @NexZhu, thanks for suggesting this and by doing so also reminding us of the importance of this feature.
I have a few issues with the implementation approach taken though:

• A regex against the URL can just as well be done by a reverse proxy (like nginx) in front of josh-proxy
• The regex approach does not play well with other josh features. It will be hard to integrate with the GraphQL API and also can be easily circumvented as soon as the workspace filter is used.

We have been doing some preliminary work on an ACL implementation that is based filters and will behave correctly in those cases.
The main reason it has not been integrated so far is that we could not decide on how to store the configuration (the ACL). I think we have been thinking to complicated (we wanted to support LDAP groups right from the start) and the approach you've taken here using a simple yaml file is better to get started and maybe even enough for plenty of use cases.
I'm sill wondering if it would make sense to have the concept of groups to avoid repeating the sames rules over and over again as soon as the number of users becomes a bit larger.

Hi @christian-schilling

• The regex approach does not play well with other josh features. It will be hard to integrate with the GraphQL API and also can be easily circumvented as soon as the workspace filter is used.

Can you explain a little what do you mean by "can be easily circumvented as soon as the workspace filter is used", I'm not very familiar with Josh's many features yet.

We have been doing some preliminary work on an ACL implementation that is based filters and will behave correctly in those cases.

Awesome! We just put together a simple working solution because we need it right now. Actually I'll be very interested if Josh can integrate with LDAP. Supporting groups will certainly bring more flexibility, and it will be especially useful when conbined with LDAP. Here's my two cents:

To do ACL, Josh need two kinds of data: user-group relationships, and rules assigned to users/groups. Maybe we can support multiple data backends based on the same model. For the user-group relationships, it can come from config file, LDAP, OIDC, etc. For the rules part, since it's Josh specific information, maybe we can read it from local config file (static), or DB (maybe support dynamic adjustment).

Can you explain a little what do you mean by "can be easily circumvented as soon as the workspace filter is used", I'm not very familiar with Josh's many features yet.

There is some documentation here and here.

If you use a workspace filter (:workspace=my_workspace), you can put any filters in the workspace file (in this case, my_workspace/workspace.josh), allowing you to see the contents of the corresponding directories.

@NexZhu: Like described in the docs @LMG pointed to, workspaces allow arbitary re composition of paths exposed as a virtual repo. As soon as a users can access (and modify) any workspace they will be able to add paths to it that they where not granted access to.
Thats why a more sophisticated check is needed that understands how filters and workspaces work.
It might not be very obvious but the recently merged 5772b02 is one step of implementing that.
I hope we can have something working with two toml files (one for user -> group mapping, and another for group -> permissions) pretty soon.

Hi @NexZhu,

I just pushed a PR implementing access rights: #561

You can see examples of how to use it in the test.
Let me know if it works for you :)

Best regards,
Louis-Marie